This invention relates to a method and software object for grouping a set of software items under a common interface. It is particularly applicable to object-oriented software applications and may be used to reduce the number of entries in a name lookup service and improve the speed of requests in a system.
From the standard microwave oven to the sophisticated database retrieval system, software is being developed at an increasingly rapid rate and the revenues generated from it are exponentially increasing. At the same time the size of software systems and applications is also increasing. Commonly a same system is run on several machines, herein referred to as nodes, each node running a portion of the applications. The nodes communicate with one another through a communication link using ATM or any other suitable communication protocol. The set of nodes interconnected by a communication device constitutes a distributed network system. Distributed processing is a powerful way to make software scaleable and to allow a single system to have components in multiple locations. Many standards for distributed processing exist and are commonly used. As a specific example, the Common Object Request Broker Architecture (CORBA) provides a basic mechanism for transparently distributing software objects across multiple processors connected to a network. Communicating CORBA objects may be written in a variety of programming languages, and may run on a variety of computer processor types. The communication, and any needed translation between the different data formats of varying processor types and programming languages, is handled automatically by CORBA. CORBA is a standard defined by the Object Management Group (OMG). For more information on the COREA standard the reader is invited to consult xe2x80x9cThe Essential CORBA: Systems Integration Using Distributed Objectsxe2x80x9d, by Thomas J. Mowbray and Ron Zahavi, Object Management Group Inc, 1998, whose content is hereby incorporated by reference.
Telecommunication software is an example of a distributed network system. Of particular interest here is object-oriented telecommunication software. Object-oriented software for telecommunication (voice or data) typically uses many small software objects that represent people, equipment such as telephones and computers and even individual telephone calls. Such small objects are commonly called fine grain objects.
A simple approach to making any kind of object-oriented application distributable is to treat each fine grain object as a separate entity. For this method, each object needs a separate object reference, entries in data tables and process/thread resources. Unfortunately this does not scale well for systems containing a large number of fine grain objects even though the code that handles message dispatching to the objects may be shared in a good implementation. The result, as the number of fine grain objects grows large, is system performance degradation. The practical limit in typical systems is on the order of hundreds of objects per processor. The large numbers of objects commonly found in telecommunication systems, sometimes millions in a large system, makes the use of this approach impractical.
Another approach is to explicitly group objects, making an object-group structure, each fine grain object being visible in the interface of the object-group structure. This has the advantage of reducing the number of objects in the tables but makes object-group boundaries visible in application code. These visible boundaries make it difficult to split or combine object-groups if the size of a system changes since the interface must be changed. This results in additional costs as well as possible errors. Also it is generally not possible to change the implementation of a class of objects to use (or stop using) object-groups, without rewriting both server and client code.
Thus, there exists a need in the industry to provide a method and apparatus for reducing the number of object references in a system such as to improve the use of resources in a software system.
For the purpose of this specification, the word xe2x80x9csystemxe2x80x9d is used to designate the entity managing the messages in the distributed network. In a specific example, the system refers to the operating system. In another specific example, system is the CORBA message system.
For the purpose of this specification, the word xe2x80x9cobjectxe2x80x9d is used to designate a collection of related data with an interface that defines the operations available on that data. The software code for the object is generally written in a programming language appropriate to its functions, such as Smalltalk, C++, Pascal, Java, or Assembler.
For the purpose of this specification, the word xe2x80x9ccontainerxe2x80x9d is used to designate a software entity that holds a collection of objects. The objects in the container are herein referred to as xe2x80x9cfine grain objectsxe2x80x9d.
For the purpose of this specification, the expression xe2x80x9cindependent objectxe2x80x9d is used to designate an object not grouped with other objects in a container.
For the purpose of this specification, the expression xe2x80x9cexternal objectxe2x80x9d is used to designate an object that is external to a specific container. For example, if objects A B and C are in the same container and object D is not a member of the container, we say that object D is an external object to A B and C.
For the purpose of this specification, the expression xe2x80x9csame Kindxe2x80x9d is used to designate object classes with the same interface irrespective of the underlying implementation of the class. For example, a Kind xe2x80x9cPRINTERxe2x80x9d may include different classes of the type xe2x80x9cLAZER 4000xe2x80x9d, xe2x80x9cINK JET 200xe2x80x9d and xe2x80x9cLAZER 3000xe2x80x9d provided the interface of these classes is the same irrespective of their individual implementation.
For the purpose of this specification, the expression xe2x80x9cpersistent namexe2x80x9d is used to designate the static name of a software entity that external software objects use to communicate with it. The persistent name is typically independent of the location of the software entity in the system. In a specific example, the persistent name of an object is in the form of a character string.
For the purpose of this specification, the expression xe2x80x9csoftware object referencexe2x80x9d is used to designate the software location of an instance of an software object in a system. This expression should be given a broad interpretation to include a pointer to actual object references, pointers to memory locations containing software references and other equivalents. Typically, within the object reference is a hardware node address that specifies the network location of the software object. In the preferred embodiment, a Name Service translates the persistent name of a software object into its software object reference. A particular object with a certain persistent name maintains its persistent name irrespective of the instantiation of that object. On the other hand, each instantiation of a certain object is typically given a different object reference that is valid only for that particular instantiation. For example, if a subsystem of a distributed software system is taken out of service then is subsequently restarted on the same node or on some other node, each object in the restarted subsystem keeps the same persistent name that it had formerly, but is given a new object reference.
In summary, the present invention provides a computer readable storage medium containing a program element for implementing on a computer a Name Service object that maps persistent names to object references.
The Name Service includes a data structure with a plurality of entries, each entry including a range of persistent names mapped to an object reference. When the Name Service receives a look-up request message from an external software object, it searches the data structure containing the entry with the persistent name range containing the persistent name submitted in the look-up request message. Next, the Name Service computes an index that is appended to the object reference associated with the range of persistent names. The combination object reference/index allows uniquely distinguishing the software object that corresponds to the persistent name submitted in the look-up request message. This feature allows reducing the number of entries in the data structure since it is no longer required to provide a separate entry for each software object.
The invention also extends to a computer system implementing the above described software Name Service object, and to a method for implementing a Name Service object.